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ABSTRACT 

VoIP applications are emerging today as an important com- 
ponent in business and communication industry. In this 
paper, we address the intrusion detection and prevention in 
VoIP networks and describe how a conceptual solution based 
on the Bayes inference approach can be used to reinforce the 
existent security mechanisms. Our approach is based on net- 
work monitoring and analyzing of the VoIP-specific traffic. 
We give a detailed example on attack detection using the 
SIP signaling protocol. 

1. INTRODUCTION 

With VoIP we inherit the adjacent security problems asso- 
ciated with the IP as well as new VoIP specific ones. Attack- 
ers can profit from the vulnerabilities of the VoIP protocols 
and architectures. Both Signaling protocols such as H.323 
and SIP (Session Initiation Protocol), and media transport 
protocols such as RTP and RTCP could be the target of 
a wide set of attacks, ranging from eavesdropping, denial 
of service, fraudulent usage and SPIT (Spam over internet 
telephony). 

Important work in both host and network intrusion detec- 
tion has been already done by the industrial and academic 
research community, focused in scope towards network in- 
trusion detection for routing, transport and application level 
protocols. However, specific approaches for VoIP are still in 
an incipient stage and we were motivated in our work to 
leverage existing conceptual solutions for the VoIP specific 
application domain. Our paper is structured as follows: a 
brief review of the possible VoIP specific threats is given in 
section [5] An introduction of the Bayesian inference theory 
is given in the section [3] Section [I] will present a detailed 
approach of a network-based intrusion detection using a sta- 
tistical Bayes model. Section overviews the related works 
and section concludes the paper. 

2. VOIP THREATS 
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Although, the SIP protocol has some security capabili- 
ties (like for instance to partially encrypt messages) and 
thus making eavesdropping and media spamming harder, 
some other threats represent real sources for major dam- 
ages. The encryption of message headers is allowed, but 
headers like To, From, Call-ID, CSeq and Via are impor- 
tant to the proxies, such that its usage is limited. TLS can 
be used for a hop by hop based encryption and end to end 
encryption, non repudiation and integrity are possible via 
S/M1ME, but performance is heavily impacted. In the fol- 
lowing paragraphs, we go through a panorama of the most 
important threats. 

Messages interception and call tracking. The SIP INVITE 

packets contain sensible informations such as the source and 
the destination of the call (To, From, Via headers), allowing 
call tracking. The duration of a call can be calculated by log- 
ging the time of the INVITE message who started the call and 
the BYE message who ended it. Interception of unencrypted 
SfP requests and handling of its values can be a preparatory 
stage to session hijacking and man in the middle attacks. 

Fraudlent usage. Malicious clients could try to bypass the 
billing procedure and to make calls to the PSTN (Public 
Switched Telephone Network) for free. Unsecured gateways, 
misconfigured dialplans and platform specific vulnerabilities 
are common causes for it. 

Password cracking and user enumerating. Some attacks 
attempt to break down the access control, like for instance 
brute force password cracking. These attacks could be pre- 
ceded by a scanning and enumeration of existing user names. 
A scanner which is looking to know the valid numbers in a 
domain will send a sequence of requests investigating the 
location server of the domain. Each request carries a differ- 
ent number or user name as destination. The scanner will 
bind between the requests and the corresponding responses 
to filter up the existent destinations. 

Call hijacking and man in the middle attack. SIP uses 
a strong authentication scheme similar to the HTTP digest. 
A SIP user agent, proxy, redirect or registrar server might 
challenge a client user agent to authenticate. In addition, 
a user agent can challenge back a proxy server to be sure 
that it also knows the shared secret. Unfortunately, only the 
server authenticates the client in most VoIP implementation 
and the following attack is possible: Bob wants to call Alice. 
Bob's phone sends an INVITE message to the proxy server 



within its domain in order to route the call towards Alice's 
domain. Trudy impersonates the proxy and redirects the call 
to its own IP address. To do so, Trudy has to create a crafted 
SIP response and put its own IP address in the Contact 
header. Bob's phone does not require the authentication of 
the proxy, so it accepts the response and redirects the call 
to pass by Trudy's machine. In figureQ a normal call setup 
is shown at the upper side and a scenario of call hijacking 
is shown at the lower side. We do not show all the SIP 
messages involved in both scenarios but just the main steps 
numbered by order of appearance. 

If the end to end authentication is missed -which is a com- 
mon case-, man in the middle scenario is possible. A ses- 
sion established between Bob and Alice could be hijacked 
by Trudy. Indeed, Trudy who has caught the INVITE in the 
origin of the session, copies the Call-ID, To and From tags 
to a new INVITE packet and increments the sequence num- 
ber CSeq. Trudy steps in and sends the crafted INVITE to 
Bob or Alice. Since no authentication is required, Trudy 
ends up by hijacking the session. She can change both me- 
dia and signaling characteristics, like for example changing 
RTP ports, adding or deleting media streams, changing the 
signaling path (Via headers) or denying signaling from any 
side to its benefit (Contact header). 

Denial Of Service (DOS). This type of attacks aims to 
affect the availability of the service. Attackers can search 
for vulnerabilities in the VoIP stack of a server to find a 
way to take it down using malformed packets. Otherwise, 
they can fill up the available bandwidth by flooding traffic 
so the server could not use the network ressources. 

CANCEL and BYE attacks might take place against the 
SIP call establishment procedure. If whenever someone tries 
to call Bob, Trudy sends a CANCEL to Bob, then Bob will 
be prevented from receiving calls. If whenever Bob tries 
to make a call, Trudy sends a CANCEL to the destination, 
then Bob will be prevented from making calls. Otherwise, 
Trudy could send a BYE to terminate a session after a few 
moments of its setup. Trudy could use proxy responses such 
as 4xx(client error), 5xx(server error) or 6xx(global error) to 
convince Bob that an error situation is preventing him from 
making calls. 

A traditional DOS can be launched against a stateful SIP 
proxy or a gateway in form of a large amount of requests with 
different Call-Ids. Distributed sources could participate 
in the attack in order of surcharging the server capacities 
(memory, CPU or bandwidth). A list of VoIP specific DOS 
could be found in |12|. 

Attacks against gateways and voice mail servers. The 
gateway between PSTN and VoIP networks is a critical point 
from the billing perspective. Most often, It is the host where 
the Call Detail Records (CDRs) are safeguarded and the 
accounting operations are proceeded. The voice mail servers 
may contain confidential informations about the customers. 
For these reasons, the gateways and the mail servers are 
the probable target for the hackers activities. These people 
will try different kinds of host intrusions or remote code 
execution and buffer overflow attacks aiming to hijack the 
configuration or to tamper with the data. 



by a more annoying voice advertising. The nature of the In- 
ternet protocols gives easy ways to stream real-time voice 
messages to a large number of destinations. When they are 
filled by automated calls, IP phones and voice-mail boxes 
will be useless. 

Media protocols related attacks. Modifications of the me- 
dia characteristics by a media protocol is not transparent for 
SIP. Actually, SIP could be classed as an out-band signaling 
and does not have control mechanisms to sense a changing 
in the media session. In addition, multimedia protocols such 
as RTP and RTCP have their own vulnerabilities. A demon- 
strative tool of the RTP play out attack was presented in £Q. 
The encryption of the RTP streams seems to be a good so- 
lution to prevent eavesdropping, but the attackers may have 
got the encryption keys by rather than a way (for instance 
if the keys are negotiated clearly in the media negotiation 
phase). 

Supporting protocols related attacks. The ARP (Ad- 
dress Resolution Protocol) poisoning attack consist in bind- 
ing the physical address of the intruder with the IP address 
of the gateway at the IP phone machine, and on binding the 
physical address of the intruder with the IP address of the 
IP phone at the gateway machine. The DNS (Domain Name 
System) poisoning attack can be also used to perform man 
in the middle attacks. MAC and IP spoofing are fundamen- 
tal flaws in the basic Internet and could not addressed from 
a particular application point of view. 

Firewall traversal. The firewalls utilized with VoIP have 
dynamic skills. They open and close RTP ports with re- 
spect to the SDP (Session Description Protocol) parameters 
during the session initiation. The firewall could be attacked 
by making it dealing with a large number of port opening 
requests so it may loose its defense functionality. 

3. INTRODUCTION TO THE BAYES INFER- 
ENCE 

Bayesian methods provide a formalism for reasoning about 
partial belief under conditions of uncertainty They are 
based on the empirically verifiable relationship between pos- 
terior(the belief we accord a hypothesis H upon obtaining 
evidence e) and prior(P(H)) probabilities: 



P(H/e) = 



P(e/H)P(H) 
P(e) 



A Bayesian network is a directed acyclic graph whose arrows 
represent causal influences and each of its nodes represents 
certain knowledge and is considered to be in one of several 
discrete states. In a Bayesian tree, each node might have 
several children and one parent. The propagation and fusion 
of the belief in a Bayesian tree are proceeded under the 
following rules: 

• The likelihood (or diagnostic) messages A are travelling 
upward the tree. 

• The prior (or causal) messages tv are travelling down- 
ward the tree. 



SPIT or SPAM over Internet telephony. The SPAM un- 
wanted messages that threaten the e-mail users will be joined 



A child is linked to its parent by a conditional prob- 
ability table (CPT) of which the elements are given 
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Figure 1: Normal and Attack scenarios 



by: 

CPTij = P(child = j /parent = i) 

Each row of the matrix is a discrete distribution over 
the child node states giving the parent node state and 
thus it sums to 1. 

• The propagation of the prior messages is given by: 

ir(child) — an(parent) • CPT (child /parent) 

where it is a row vector and a is a constant to normalize 
the distribution. 

• The propagation of the likelihood messages is given by: 

\to.par>int(child) = CPT (child /parent) • X(child) 
where A is a column vector. 

• The likelihood messages are fused together by an ele- 
mentwise multiplication: 

Li(parent) = Apparent; (child) 

child£children(parent) 

\(parent) is obtained by normalizing the vector 
L(parent) to the unit sum. 

• Finally, the belief over the states at a node is ob- 
tained by an elementwise multiplication of X(parent) 
and ^(parent) and then normalizing the resulting vec- 
tor by an appropriate constant f3: 

BELi = /3wi\i 

4. BAYES MODEL TO DETECT INTRUSIVE 
SIP TRAFFIC 

In this section, we present the exercise of applying the 
Bayes tree model into a network-based intrusion detection 
solution for VoIP. The model was firstly applied in the intru- 
sion detection domain as a component of the broad EMER- 
ALD system to detect intrusive TCP sessions The 
source of data for our detector engine is captured SIP traffic. 
The packets of other VoIP protocols such as RTP or VoIP 
supporting (DNS) could be also an important source of data 
which could be exploited in future works. 



4.1 The model structure 

In our context, the source of an incoming request is the 
value of the last Via header of this request, because the re- 
sponse will be routed back to arrive to this address. The 
destination of a request can be found in the first line of the 
request. From and To headers are logical source and destina- 
tion. In the following example, here . com is the SIP source 
of the ACK request, and UserBSthere . com is the destination. 

ACK sip: UserB@there.com SIP/2.0 

Via: SIP/2. O/UDP ss2 .wcom. com: 5060 ;branch=721e418c4 . 1 

Via: SIP/2. O/UDP ssl .wcom. com: 5060 ;branch=2d4790. 1 

Via: SIP/2. 0/UDP here . com: 5060 

From: BigGuy <sip :UserA@here . com> 

To: LittleGuy <sip :UserB@there . com> ;tag=314159 

Call-ID: 12345601@here.com 

CSeq: 1 ACK 

Content-Length: 

To construct the model, choose the different variables, 
study the dependency relationships between variables and 
set the different parameters, a large empirical database is 
needed. However, and due to our poverty to real world 
traces, we have recourse to our knowledge of how SIP works 
and how attacks are performed to extract a first prototype 
that could be implemented to defend a VoIP site and up- 
dated increasingly while new experiences are acquired by the 
time. 

We use a naive Bayes model which is a 2-level tree formed 
by one root node and several leaf nodes. The root represents 
the traffic class which is unobservable. The leafs represent 
the directly observable evidences. We assume that the child 
nodes are conditionally independent given the parent: 

P(child\ / parent) = P(childl/child2, parent) 

V child!, child2 £ children(parent) . 

The belief propagation and updating is done periodically 
and we call it the inference process. The period could be con- 
figured as a count of occurred events number or as a measure 
of elapsed time. The events are either a SIP message cap- 
tured or an exception thrown in deciphering or parsing. Dur- 
ing the period time, the events update the values of variables 
at the leaf nodes so at the end of each period the likelihood 



messages could be estimated. While the most important in 
the interpretation at the class traffic root is to distinguish 
between attack and non attack cases, our model includes the 
following states of interest: NORMAL, DOS, SCAN, PASS- 
WORD CRACKING, FIREWALL TRAVERSAL and SPIT. 

The observed variables at the leaf nodes are of three types: 
Request Intensity(RI), Error Response Intensity(ERI) and Pars- 
ing Error Intensity(PEI) are intensity measures, Number of 
Different Destinations, Max Number of Dialogs in Waiting 
State and Number of opened RTP ports are high water marks, 
finally Request Distribution and Response Distribution are dis- 
tribution measures. Intensity measures are exponentially 
decayed counts. Noting that the codes of the SIP error re- 
sponses are between 300 and 699, let I(resp_code) — 1 if 
300 < resp_code and I{resp_code) — otherwise. Intensity 
measures are computed by the following formulas: 

• Rlreq = e kAt ■ RI req -± + 1.0 J 

• ERIresp = e kAt ■ ERIresp-! + I (respjcode); 

• PEh rr = e feA * • PEI er r-l + 1.0 J 

Where At is the time between the present and the immedi- 
ately preceding event and k is a decay constant and is < 0. 
The most appropriate is to measure the time chronologically 
in case of Rl and by events count in case of ERI and PRI. 
Like that, An exponentially decayed count does not grow 
without a bound for normal behavior and well chosen de- 
cay constants. We divide the intensity range into several 
intervals. At each end of period, the intensity measure falls 
under one interval. So, the likelihood probability is 1 for the 
matched interval and for all other ones. 

We initiate counters to record the high water marks mea- 
sures. The max number of dialog in waiting state is incre- 
mented for each request which is responded but it holds the 
state machine of the dialog waiting for an ACK. Once time 
the ACK is received, the counter is decremented by one. The 
maximum reached by the counter at any time is tracked. 
Like the intensity measures, we divide the high water mark 
range into several intervals and we assign appropriately the 
likelihood probabilities at the end of a period. After the 
inference process is finished, we reset all the counters. 

Between 2 inference processes, we track the count of each 
request to build up the Request Distribution. Likewise, the 
responses are grouped by their respective classes and counted 
to build up the Response Distribution. The distribution is 
taken as the likelihood vector of the leaf node. The figure 
depicts the scheme of our model. 

4.2 Example of the attack detection process 

We aim in this section to go through the inference process 
starting from a trace of attack to clarify and motivate our 
approach. The calculation is not totally complete because 
we have no empirical idea about the prior probabilities of the 
different traffic classes so the propagation will be in only one 
direction rather than two (upward). 

The following trace is an example of a URI scanning (enu- 
merating) attack in which the attacker tries to call 9 differ- 
ent SIP URIs behind a user agent serving multiple clients. 
We collect for each dialog the incoming requests from the 
attacker and the outgoing responses from the user agent. 

Dialog 1: INVITE -> 404 Not Found -> ACK 
Dialog 2: INVITE -> 484 Address Incomplete -> ACK 
Dialog 3: INVITE -> 100 Trying -> 503 Service 
Unavailable — > ACK 



Dialog 4: INVITE — > 100 Trying — > 180 Ringing — > 
CANCEL — > 200 OK (CANCEL) — > 487 Request Terminated 
— > ACK Good number, the attacker hangs up immediately. 
Dialog 5: INVITE -> 404 Not Found -> ACK 
Dialog 6: INVITE — > 484 Address Incomplete -» ACK 
Dialog 7: INVITE — > 100 Trying — > 503 Service 
Unavailable — > ACK The number could be right but his 
owner is not registered at the moment 

Dialog 8: INVITE -> 100 Trying -> 180 Ringing -> 200 
OK — > ACK — > BYE — > 200 OK Good number, the call is 
answered, the attacker hangs up. 
Dialog 9: INVITE -> 404 Not Found -> ACK 

Let us first set up the CPT matrices that relates between 
the root and the children nodes. Theses matrices are nor- 
mally evaluated by a learning phase, but here we will set 
them manually according to protocol semantics. For sim- 
plicity sake, we will divide the range of each measure (except 
distributions) into a few number of categories. More exper- 
iments with traces of attacks will allow us in the future to 
refine the number and the borders of categories. We assume 
that no S/MIME encryption mechanism was in place, and 
no parsing errors have occurred. The PCE is always so 
the related CPT has no influence on the inference process 
and it is not shown. In the Request Intensity formula, we set 
the decay rate at —0.35 for a half-life time of 2 seconds. To 
fill up the CPT tables, we asked such kind of questions: If 
the traffic is of kind DOS, what is the probability to have 
RI > 10. 



Request Intensity 


0-10 


> 10 


NORMAL 


1 





SCAN 


1 





SPIT 


1 





DOS 





1 


PASSWORD CRACKING 


1 





FIREWALL TRAVERSAL 


1 






In the Error Response Intensity formula, we measure the 
time as events related. We set the decay rate as —0.15 for 
a half-life time near of 5 events. We set the CPT matrix to 
the next: 



Error Response Intensity 


0-4 


> 4 


NORMAL 


1 





SCAN 


0.2 


0.8 


SPIT 


0.2 


0.8 


DOS 





1 


PASSWORD CRACKING 





1 


FIREWALL TRAVERSAL 


1 






We set the CPT matrix of the Number of Destinations to the 

next: 



Number of Destinations 


0-7 


> 7 


NORMAL 


1 





SCAN 





1 


SPIT 





1 


DOS 


0.8 


0.2 


PASSWORD CRACKING 


1 





FIREWALL TRAVERSAL 


0.8 


0.2 



We set the CPT matrix of the Number of Opened RTP ports 

to the next: 



Number of Opened R'l'P ports 


0-10 


> 10 


NORMAL 


1 





SCAN 


1 





SPIT 


0.8 


0.2 


DOS 


0.8 


0.2 


PASSWORD CRACKING 


1 





FIREWALL TRAVERSAL 





1 
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Figure 2: Bayes model for SIP 



We set the CPT matrix of the Max of Dialogs in Waiting 
State to the next: 



Max Number of Dialogs in Waiting State 


0-10 


> 10 


NORMAL 


1 





SCAN 


0.8 


0.2 


SPIT 


1 





DOS 


0.1 


0.9 


PASSWORD CRACKING 


0.8 


0.2 


FIREWALL TRAVERSAL 


0.8 


0.2 



We restrict the Request Distribution to only INVITE(I) , RE- 
GISTER(R) , ACK(A) , CANCEL(C) and BYE (B) SIP methods. 
We set the CPT matrix to the next: 



Request 


1 


R 


A 


C 


B 


NORMAL 


0.30 


0.10 


0.30 


0.10 


0.10 


SCAN 


0.40 


0.05 


0.40 


0.10 


0.05 


SPIT 


0.40 


0.00 


0.40 


0.00 


0.20 


DOS 


0.90 


0.10 


0.00 


0.00 


0.00 


PA. CR. 


0.10 


0.40 


0.40 


0.00 


0.00 


FI. TR. 


0.40 


0.00 


0.40 


0.00 


0.20 



The SIP responses are categorized according to their differ- 
ent classes. We set the CPT matrix of the Response Distri- 
bution to the next: 



Request 


lxx 


2xx 


3xx 


4xx 


5xx 


6xx 


NORMAL 


0.30 


0.30 


0.05 


0.05 


0.05 


0.05 


SCAN 


0.10 


0.05 


0.05 


0.70 


0.10 


0.00 


SPIT 


0.30 


0.20 


0.05 


0.20 


0.20 


0.05 


DOS 


0.20 


0.10 


0.20 


0.20 


0.20 


0.10 


PA. CR. 


0.20 


0.00 


0.10 


0.60 


0.05 


0.05 


FI. TR. 


0.30 


0.20 


0.05 


0.20 


0.20 


0.05 



Let us now fix the values of different variables observed at 
the child nodes and then assign the likelihood probabilities. 
Let us assume that the attacker launches its queries into 
intervals of five seconds to give the appearance of a nor- 
mal behavior. The calculus of the Request Intensity gives a 
value of 2.424. The result could be justified because such 
type of attack does not abnormally rise the Request Inten- 
sity contrary to what a DOS attack will do. The likelihood 
vector at the Request Intensity child is A = (1 0) because 
the intensity = 2.424 < 10. The likelihood vector passed to 
the root node is A io _ p(lren t = (111011). The calculus 



of the ERI gives a value of 2.70. The likelihood vector is 
A = (1 0) because the intensity = 2.70 < 4. The likelihood 
vector passed to the root is At _ paren t = (1 0.2 0.2 1). 
We assume that the Number of Destinations is 9 (A = (0 1) 
and Xto.parent = (0 1 1 0.2 0.2)) and that the Num- 
ber of RTP ports opened is less than 10 (A = (1 0) and 
Ato_ P arent = (11 0.8 0.8 1 0)). We assume that each dia- 
log is closed before the subsequent dialog starts. The Max 
Number of Dialog in Waiting State is 1. A = (1 0) and 
\to-parent = (1 0.8 1 0.1 0.8 0.8). The Request Distribu- 
tion of the trace according to the SIP methods involved is 
next: 



method 


1 


R 


A 


c 


a 


A 


9 





9 


1 


1 



\to_parent = (5.6 7.35 7.4 8.1 4.5 7.4). The Response Distri- 
bution of the trace according to the response classes is next: 



class 


lxx 


2xx 


3xx 


4xx 


5xx 


6xx 


A 


7 


2 





6 


2 






Xtojparent = (3.1 5.2 4.1 3.2 5.1 4.1). 

Now we can fuse all the \to_ pa rent from children by elemen- 
twise multiplication: Li = J~[ c X-tojparent^c); 1 < i < 6. 
We obtain the vector L = (0 6.11 4.85 0). The belief 
about the trace is obtained by normalizing L to the unit 
sum. BEL = (0 0.56 0.44 0). The trace is either SCAN 
or SPIT. This result could be explained because these two 
types of attacks are very similar. To refine the scales of dif- 
ferent observed variables (intensities and high water marks) 
by using a greater number of intervals would better differ- 
entiate between these two types. 

5. RELATED WORKS 

Intrusion detection systems (IDSs) have been deployed as 
a second defense line behind the intrusion prevention tech- 
niques and many research papers have been written on this 
topics. The conceptual building blocks of our method is the 
article of Valdes and Skinner in 

With the deployment of web services, the designers of 
IDSs recognize more and more the importance of a spe- 



cific service knowledge such as implementation vulnerabil- 
ities and protocol weaknesses. A service specific anomaly 
detector which checks DNS and HTTP traffic is proposed in 
A multi-model approach to the detection of web based 
attacks has been recently published in 

VoIP security became a major research topic over the last 
years. A general introduction to it can be found in [5]. In 
|1U| we find a discussion about the vulnerabilities in small 
and home VoIP gateways and a proposal of some practi- 
cal recommendations. Sensors at multiple layers to protect 
IP telephony from DOS attacks are inspired from works on 
TCP in 0- The authors of [U] highlights the difference be- 
tween the control of the SPAM email and that of SPIT. 
They propose a voice SPAM control algorithm called Pro- 
gressive Multi Gray-Leveling that fits in VoIP settings. In 
another way, the authors of propose social networks and 
reputation rating to deal with SIP SPAM. More similar to 
our work is the proposed intrusion detection framework de- 
scribed in |13|. Our approach is different with respect to 
it, since we use a Bayesian model capturing temporal and 
behavioral anomalies. 

6. CONCLUSION 

Intrusion detection and prevention is of major importance 
in VoIP networks. We have proposed in this paper an ap- 
proach for VoIP intrusion detection based on prior work 
done in the intrusion detection community. We have jus- 
tified the security needs in the VoIP environmet by a brief 
survey of the most relevant threads. The essential contribu- 
tion is the modelling of SIP traffic and threat related entities 
so that SPIT, enumeration and denial of service can be de- 
tected. Other attacks remain still an open issue: man in 
the middle and call hijacking require a different kind of se- 
curity mechanisms. A complementary solution is to avoid 
them, by managing the authentication and access control 
infrastructure. Future work will consist in releasing an open 
source based intrusion detection tool as well as performing 
real world operational evaluation of our solution. 
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